1. Field of the Invention
This invention relates in general to database management systems performed by computers, and in particular, to the optimization of queries using automatic summary tables.
2. Description of Related Art
Computer systems incorporating Relational DataBase Management System (RDBMS) software using a Structured Query Language (SQL) interface are well known in the art. The SQL interface has evolved into a standard language for RDBMS software and has been adopted as such by both the American Nationals Standard Institute (ANSI) and the International Standards Organization (ISO).
For most RDBMS software, combinations of base tables and views are used to access data stored in the database. A view definition includes a query that, if processed, provides a temporary result table based on the results of the query at that point in time. Using an INSERT statement and an appropriately defined table in the database, the temporary results table can be stored in the database. To refresh this table, the user would need to perform a DELETE from the table and then perform the INSERT again.
Users can directly query against a table in this manner, provided that the users are aware how the results were derived. Generally, the RDBMS software is not aware that such a table is any different from any other table in the database. However, this table cannot be used by an optimizer within the RDBMS software to improve performance, even though the table may contain data that would drastically improve the performance of other queries.
This leads to the notion of automatic summary tables (ASTs) or materialized views as envisioned by the present invention. These tables are similar to the created table described above, except that the definition of the table is based on a “full select” (much like a view) that is materialized in the table. The columns of the table are based on the elements of the select list of the full select.
In the present invention, with properly defined automatic summary tables, the RDBMS software is now aware how the result in the summary table was derived. When an arbitrarily complex query is submitted, an optimizer in the RDBMS software can now consider using the summary tables to answer the query, which is a technique that requires:                performing matching between the query and summary table definition so as to determine if the summary table was derived in such a way that it can be used as a starting point to satisfy the query.        performing costing to determine whether the query can be answered more efficiently by using the summary tables.        
However, the current state of the art is that costing is performed using simple heuristics that do not consider the myriad of factors that can influence query execution such as the access paths available for accessing an AST, the cost of compensation, table properties such as order, partitioning, and uniqueness, the database configuration, and so on.